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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.661 Configuration Management (CM); Kernel CM requirements 

32.662 Configuration Management (CM); Kernel CM Information Service (IS) 

32.663 Configuration Management (CM); Kernel CM Integration Reference Point (IRP): Common Object 
Request Broker Architecture (CORE A) Solution Set (SS) 

32.664 Configuration Management (CM); Kernel CM Integration Reference Point (IRP): Common 
Management Information Protocol (CMIP) Solution Set (SS) 

Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration 
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by 
functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service (QOS). The CM actions are 
initiated either as single actions on single NEs of the 3G network, or as part of a complex procedure involving actions 
on many resources/objects in one or several NEs. 
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Scope 



The present document defines Integration Reference Point (IRP) through which an IRP Agent' (typically an Element 
Manager or Network Element) can communicate Configuration Management related information to one or several 
IRPManagers' (typically Network Managers). 

The function of this Kernel CM IRP Information Service is to define an interface that provides the essential CM 
services. While it is not expected that the Kernel CM IRP alone will provide adequate CM capability, The Kernel CM 
IRP is expected to provide the common supporting capability required for other IRPs such as the Basic CM IRP or the 
Bulk CM IRP, each of which require the Kernel CM IRP. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[4] 3GPP TS 32.312: "Telecommunication management; Generic Integration Reference Point (IRP) 

management; Information Service (IS)". 

[5] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[6] 3GPP TS 32.672: "Telecommunication management; Configuration Management (CM); State 

Management Integration Reference Point (IRP): Information Service (IS)". 

[7] ITU-T Recommendation X.710 (1997): "Information technology - Open Systems Interconnection - 

Common Management Information Service". 

[8] ITU-T Recommendation X.721 (1992): "Information technology - Open Systems Interconnection - 

Structure of Management Information: Definition of management information". 

[9] ITU-T Recommendation X.730 (1992): "Information technology - Open Systems Interconnection - 

Systems Management: Object Management Function". 

[10] ITU-T Recommendation X.733 (1992): "Information technology - Open Systems 

Interconnection - Systems Management: Alarm reporting function". 

[11] -[12] Void. 

[13] 3GPP TS 32.300: "Telecommunication management; Configuration Management (CM); Name 

convention for Managed Objects". 

[14] 3GPP TS 32.600: "Telecommunication management; Configuration Management (CM); Concept 

and high-level requirements". 
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[15] ITU-T Recommendation X.720: "Information technology - Open Systems Interconnection - 

Structure of management information: Management information model". 

[16] 3GPP TS 32.623: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Common Object Request Broker 
Architecture (CORE A) Solution Set (SS)". 

[17] 3GPP TS 32.643: "Telecommunication management; Configuration Management (CM); UTRAN 

network resources Integration Reference Point (IRP): Common Object Request Broker 
Architecture (CORE A) Solution Set (SS)". 

[18] 3GPP TS 32.642: "Telecommunication management; Configuration Management (CM); UTRAN 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to TS 32.101 [1], TS 32.102 [2] and TS 32.600 [14]. 

association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings, 

(2) reference attributes, and 

(3) association objects. 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently however, all (non-containment) associations are modelled by means of reference 
attributes of the participating MOs. 

Managed Element (ME): instance of the Managed Object Class G3ManagedElement 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the 
objects that belong to the class. Furthermore, an MO class can have operations that represent the behaviour relevant for 
that class. An MO class may support notifications that provide information about an event occurrence within a network 
resource. 

Management Information Base (MIB): A MIE is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIE consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes, and 

(3) a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIE definition. Figure 3.1 depicts the relationships 
between a Name space and a number of participating MOs (the shown association is of a non-containment 
type). 
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^Namespace (containment hierarhy) 
O MO > MIB 
Association 



Figure 3.1 : Relationships between a Name space and a number of participating MOs 

Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see TS 32.300 [13]) restricts the name 
space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the lub interface towards the RNC. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DN Distinguished Name (see TS 32.300 [13]) 

EM Element Manager 

FM Fault Management 

IDL Interface Definition Language 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MO Managed Object 

MOC Managed Object Class 

MOI Managed Object Instance 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

PM Performance Management 

RDN Relative Distinguished Name (see TS 32.300 [13]) 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

VSE Vendor Specific Extensions 
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4 System overview 

4.1 System context 

Figures 4. 1 and 4.2 identify system contexts of the IRP defined by the present specification in terms of its 
implementation called IRP Agent and the user of the IRP Agent, called IRPManager. For a definition of IRPManager and 
IRPAgent, see TS 32.102 [2]. 

The IRPAgent implements and supports this IRP. The IRPAgent can reside in an Element Manager (EM) or a Network 
Element (NE) (see also [2] clause 8). In the former case, the interfaces (represented by a thick dotted line) between the 
EM and the NEs are not the subject of this IRP. 

An NE can be managed via System Context A or B. The criterion for choosing System Context A or B, to manage a 
particular NE, is implementation dependent. An IRPAgent shall support one of the two System Contexts. By observing 
the interaction across the Itf-N, an IRPManager cannot deduce if the EM and NE are integrated in a single system or if 
they run in separate systems. 



IRPManager 



NM 



IRPAgent 



EM 



NEs 



Itf-N 



Notification IRP 
Kernel CM IRP 



Figure 4.1 : System Context A 
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Figure 4.2: System Context B 



4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory /Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to TS 32.102 [2]. 
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An IRP Agent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

rules for vendor-specific extensions remain to be fully specified, and 

many scenarios under which IRPManager and IRP Agent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor-specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 

5 Modelling approach 

This clause identifies the modelling approach adopted and used in this IRP. 
As described in TS 32.101 [1], an IRP comprises the following components: 

(1) an IRP Information Model that specifies the interface in a protocol neutral manner, defined as an Information 
Service and/or one or more Network Resource Models, 

(2) a number of IRP Solution Sets that provide the actual realization of the operations and notifications defined in 
the IRP Information Model for each protocol environment. 

The present document defines one such Information Service - the Kernel CM IRP: IS. 

The IRP Information Service is a specification of the operations and notifications that are visible over the IRP. These 
operations/notifications are generic in the sense that they do not specify the Managed Objects that are 
retrieved/manipulated/informed about over the interface, and thus this IS is independent of the NRM being managed. 

5.1 IRP Information Service modelling approach 

The IRP Information Service of the subject IRP specifies a number of protocol-independent operations and notifications 
that are needed by an IRPManager to retrieve CM information from an IRP Agent. 

The operations and notifications of the IRP Information Service are mainly based on the principles of the Common 
Management Information Service (CMIS) defined in ITU-T Recommendation X.710 [7] and ITU-T Recommendation 
X.721 [8] (M-GET etc.). Note however, that the Information Service of the subject IRP is focused on the essential 
operations and notifications needed for CM purposes and thus only covers a subset of the operations/notifications 
defined in ITU-T Recommendation X.710 [7]/ITU-T Recommendation X.721 [8]. 

It is expected that most Solution Sets will implement the operations and notifications by mapping them to standard 
operations (and possibly standard notifications) that are applicable in the corresponding protocol environment. 
A CMIP Solution Set should for instance map the operations to the more generic operations defined in CMIS, an SNMP 
Solution Set should map the operations to applicable SNMP operations, and a CORBA Solution Set should map the 
operations to applicable OMG/CORBA services. 

6 Information Object Classes (lOCs) 

6.1 Imported Information entities and local labels 



Label reference 


Local label 


32.622 [5], information object class, Top 


Top 


32.622 [5], information object class, IRPAgent 


IRPAgent 


32.622 [5], information object class, GenericIRP 


GenericIRP 


32.312 [4], information object class, IVIanagedGenericIRP 


IVIanagedGenericIRP 
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6.2 Class diagram 

This sub-clause introduces the set of information object classes (lOCs) that encapsulate information within the 
IRP Agent. The intent is to identify the information required for the KernelCmIRP Agent implementation of its 
operations and notification emission. This sub-clause provides the overview of all support object classes in UML. 
Subsequent sub-clauses provide more detailed specification of various aspects of these support object classes. 

6.2.1 Attributes and relationsinips 



containment 



+container «ProxyClass» 
— O ManagedEntity 

1 



/ +content 
0..n 



«lnfomationObjectClass» 
IRPAgent 



t 1 

«lnfomationObjectClass» 
KernelCmIRP 



6.2.2 iniieritance 



«lnfomationObjectClass» 
Top 




«lnfomationObjectClass» 
GenericIRP 



«lnfomationObjectClass» 
ManagedGenericIRP 



«lnfomationObjectClass» 
KernelCmIRP 




«ProxyClass» 
ManagedEntity 
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6.3 Information Object Class Definitions 

6.3.1 KernelCmIRP 
6.3.1.1 Definition 

KernelCmIRP is the representation of the Kernel configuration management capabilities specified by the present 
document. This IOC inherits fi^om ManagedGenericIRP IOC specified in TS 32.312 [4]. 

6.3.2 ManagedEntity 
6.3.2.1 Definition 

The IOC ManagedEntity represents the role that can be played by an instance of an IOC defined in Network 
Resources Models, e.g. Generic Network Resource Model, Core Network Resource Model, UTRAN Network Resource 
Model or GERAN Network Resource Model. 

6.4 Information relationship definitions 

6.4.1 containment (M) 

6.4.1.1 Definition 

This represents the relationship containment as defined in ITU-T Recommendation X.720 [15]. 

6.4.1.2 Role 



Name 


Definition 


container 


It represents the capability, for an instance of a ManagedEntity, to contain other objects. 


content 


It represents the capability, for an instance of a ManagedEntity, to be contained in another object. 



6.4.1.3 Constraint 



Name 



Definition 



inv noSelfContainment 



No instance of the IOC ManagedEntity can play both roles container and content in the same 
instance of the relationship containment. 
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Interface Definition 



7.1 Class diagram 



« lnterface» 
KernelCMOperations 

-getNRMIRPVersionO 




Inform ationObjectClass> 
KemelCMIRP 



<<mayuse» 



«mayuse» 



«Notification» 
KernelCMNotifications_1 



+ notifyObjectCreationO 



«mayuse>> \ 

«may tise» 



<<Notification>> 
KernelCMNotifications 5 



- notiifyStateChangeO 



<<Notification» 
KernelCMNotifications_4 



+ notifyCMSynchronizationRecomm ended (} 



«Notification» 
KemelCMNotifications_2 

+ notifyObjectDeletionO 

\ 



<<Notification>> 
KernelCMNotifications_3 

+ notifyAttributeValueChangeO 

/ 



«agent-internal-usage» 



^ / 

<<agent-internal-usage» ' 

\ <<agent-intfernal-usage» 

\ / 

^^ k 

«lnformationObjectClass» 

NotificationIRP ^ 

-^ (from TS 32.302) ^ 



<<agent-internal^usage» 



«agent-internal-usage» 



7.2 



Generic rules 



Rule 1: Each operation with at least one input parameter supports a pre-condition valid_input_parameter which 
indicates that all input parameters shall be valid with regards to their information type. Additionally, each such 
operation supports an exception operation_failed_invalid_input_parameter which is raised when pre-condition 
valid_input_parameter is false. The exception has the same entry and exit state. 

Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditions 
supported_optional_input_parameter_xxx where "xxx" is the name of the optional input parameter and the pre- 
condition indicates that the operation supports the named optional input parameter. Additionally, each such operation 
supports an exception operation_failed_unsupported_optional_input_parameter_xxx which is raised when (a) the pre- 
condition supported_optional_input_parameter_xxx is false and (b) the named optional input parameter is carrying 
information. The exception has the same entry and exit state. 

Rule 3: Each operation shall support a generic exception operation_failed_internal_problem that is raised when an 
internal problem occurs and that the operation cannot be completed. The exception has the same entry and exit state. 
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7.3 Interface KernelCmlRPOperations 

7.3.1 Operation getNRMIRPVersion (M) 



7.3.1.1 



Definition 



When the IRPManager invokes getNRMIRPVersion to find out the Network Resource IRP SS document versions 
(IRPVersions) supported by the IRP Agent, the IRP Agent shall respond, via the versionNumberList output 
parameter, with a list of supported Network Resource IRPversions. An example of this return value can contain two 
IRPVersions, where one indicates the 3GPP Generic Network Resource IRPVersion (e.g. "TS 32.623 V4.2" in case of 
CORBA implementation) while the other indicates the 3GPP UTRAN Network Resource IRPVersion (e.g. "TS 32.643 
V4.r' in case of CORBA implementation). 

It is expected that vendors may provide vendor-specific extended capabilities and features (VSE) that are based on a 
3GPP published specification. It is further expected that the vendor will publish these VSE in a document with an 
unambiguous identification. 

If an IRP Agent does not support VSE, the vSEVersionNumberList parameter shall contain no information. 

If an IRP Agent supports VSE, the vSEVersionNumberList parameter shall contain identification of one or more 
documents published by the vendor. The versionNumberList shall contain the IRPVersions indicating the 3GPP 
Network Resource IRP specifications on which the VSE is based. The versionNumberList may only identify 
IRPVersions that are consistent with the requirements of clause 4.2 of the present document and similar requirements 
statements in all CM and Network Resource IRPs. The convention to identify the vendor-specific document is not a 
subject of the present document. It is recommended that the identification should include (a) the 3GPP IRPVersion on 
which the VSE is based (b) the name of the vendor and (c) the identification of the VSE document and/or its version. 
The inclusion of the part-(b) is to avoid possible name conflict in a multi-vendor environment. An example would be 
"TS 32.642 V4.0 Ericsson v. 1". This sample indicates the identification of a document published by Ericsson that 
specifies a Ust of VSE that is based on the TS 32.642 V4.0.x". Note in this example, the IRPVersion "TS 32.642 V4.0" 
shall also be present in the versionNumberList. 

The lists returned by versionNumberList and vSEVersionNumberList shall not contain duplicates. 



7.3.1.2 

None. 



Input parameters 



7.3.1.3 



Output parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


versionNumberList 


M 


IVIanagedGenericlRP.iRPVersion 


It carries one or more SS version numbers 
supported by this IRP agent. 


vSEVersionNumberList 


M 


ManagedGenericlRP.iRPVersion 


It carries one or more identifications of vendor 
published documents containing VSE NRMs 
specifications. 


status 


M 


ENUIVI (Operation succeeded, 
Operation failed) 


If operation_failed_internal_problem status = 
OperationFailed. 



7.3.1.4 Pre-condition 

None specific. 

7.3.1.5 Post-condition 

None specific. 
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7.3.1.6 Exceptions 

None specific. 



7.4 



Interface KernelCmlRPNotifications 1 



7.4.1 notifyObjectCreation (O) 



7.4.1.1 



Definition 



IRP Agent notifies the subscribed IRPManager that a new Managed Object has been created and that the new object 
satisfies the filter constraint expressed in IRPManager" s subscribe operation (see TS 32.302 [3]). This notification 
is based on the ob jectCreation notification type specified in ITU-T Recommendation X.721 [8] and ITU-T 
Recommendation X.730 [9] (difference compared to these specifications are indicated in the description below). 



7.4.1.2 



Input Parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M,F 


IVIanagedEntity.objectClass 


Notification header - see [3]. 


objectlnstance 


M,F 


IVIanagedEntity.objectlnstance. 


Notification header - see [3]. 


notificationid 


M 


This carries the semantics of 
notification identifier. 


Notification header - see [3]. 


eventJime 


M,F 


IVIanagedEntity.creationTlme 


Notification header - see [3]. 


systemDN 


C,F 


IRPAgent.systemDN where the 
IRPAgent is related to the 
KernelCmlRP. 


Notification header - see [3]. 


notificationType 


M,F 


Mapped to notificationType in [3] - see 
annex A 


Notification header - see [3]. 


correlatedNotifications 





See comment. 


A set of notifications that are correlated to the 
subject notification. Defined in 
ITU-T Recommendation X.733 [10]. 


additionalText 





Text. 


It can contain further information on the creation 
of the IVIQ. 


sourcelndicator 





ENUM( 

Resource_operation, 
Management_operation, 
Unknown) 


This parameter, when present, indicates the 
source of the operation that led to the 
generation of this notification. It can have one of 
the following values: 
resource operation: The notification was 
generated in response to an internal operation 
of the resource; 

management operation: The notification was 
generated in response to a management 
operation applied across the managed object 
boundary external to the managed object; 
unknown: It is not possible to determine the 
source of the operation. 


attributeList 





LIST OF SEQUENCE <AttributeName, 
AttributeValue> 


The attributes (name/value pairs) of the created 
MO. 


NOTE: F in the Qualifier column denotes a Filterable Parameter. 



7.4.1.3 



Triggering Event 



7.4.1.3.1 From-state 

stateBeforeObjectCreation. 



Assertion Name 


Definition 


StateBeforeObjectCreation 


The number of instances of the IOC ManagedEntity is equal to N. 
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7.4.1.3.2 To-state 

state AfterObjectCreation. 



Assertion Name 


Definition 


stateAfterObjectCreation 


The number of instances of the IOC ManagedEntity is equal to N + 1 . 



7.5 



Interface KernelCmlRPNotifications 2 



7.5.1 notifyObjectDeletion (O) 



7.5.1.1 



Definition 



IRP Agent notifies the subscribed IRPManager of a deleted Managed Object. The IRP Agent invokes this notification 
because the subject notification satisfies the filter constraint expressed in the IRPManager subscribe operation (see 
TS 32.302 [3]). This notification is based on the ob jectDeletion notification type specified in ITU-T 
Recommendation X.721 [8] and ITU-T Recommendation X.730 [9] (difference compared to these specifications are 
indicated in the description below). 

Note that when a Managed Object is deleted, all subordinate Managed Objects (i.e. the complete sub-tree of the MIB) 
are also deleted. Furthermore, all associations where the Managed Object participates are deleted. 



7.5.1.2 



Input Parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M,F 


ManagedEntity.objectClass 


Notification header - see [3]. 


objectlnstance 


M,F 


IVIanagedEntity.distinguishedName. 


Notification header - see [3]. 


notificationid 


M 


This carries the semantics of notification 
identifier. 


Notification header - see [3]. 


eventJime 


M,F 


IVIanagedEntity.deletionTime 


Notification header - see [3]. 


systemDN 


C,F 


IRPAgent.systemDN where the IRPAgent 
is related to the KernelCmlRP. 


Notification header - see [3]. 


notificationType 


M,F 


Mapped to notificationType in [3] - see 
annex A 


Notification header - see [3]. 


correlatedNotifications 





See comment 


A set of notifications that are correlated to 
the subject notification. Defined in ITU-T 
Recommendation X.733 [10]. 


additionalText 





Text 


It can contain further information on the 
deleted MO. 


sourcelndicator 





ENUM( 

Resource_operation, 
Management_operation, 
Unknown) 


This parameter, when present, indicates the 
source of the operation that led to the 
generation of this notification type. It can 
have one of the following values: 

• resource operation: The notification was 
generated in response to an internal 
operation of the resource; 

• management operation: The notification 
was generated in response to a 
management operation applied across 
the managed object boundary external 
to the managed object; 

• unknown: It is not possible to determine 
the source of the operation. 


attributeList 





LIST OF SEQUENCE <AttributeName, 
AttributeValue> 


The attributes (name/value pairs) of the 
deleted MO. 


NOTE: F in the Qualifier column denotes a Filterable Parameter. 
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7.5.1.3 



Triggering Event 



7.5.1.3.1 From-state 

stateBeforeObjectDeletion. 



Assertion Name 


Definition 


StateBeforeObjectDeletion 


The number of instances of tlie IOC ManagedEntity is equal to N. 



7.5.1.3.2 To-state 

state AfterObjectDeletion. 



Assertion Name 


Definition 


stateAfterObjectDeletion 


The number of instances of the IOC ManagedEntity is equal to N - 1 . 



7.6 



Interface KernelCmlRPNotifications 3 



7.6.1 notifyAttributeValueChange (O) 



7.6.6.1 



Definition 



IRP Agent notifies the subscribed IRPManager of a change of one or several attributes of a Managed Object in the 
NRM. The IRP Agent invokes this notification because the subject notification satisfies the filter constraint expressed in 
the IRPManager subscribe operation (see TS 32.302 [3]). This notification is based on the 
attributeValueChange notification type specified in ITU-T Recommendation X.721 [8] and ITU-T 
Recommendation X.730 [9] (difference compared to these specifications are indicated in the following table). 
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7.6.6.2 



Input Parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M,F 


Managed Entity. objectClass 


Notification header - see [3]. 


objectlnstance 


M,F 


IVIanagedEntity.distinguishedName. 


Notification header - see [3]. 


notificationid 


M 


This carries the semantics of notification 
identifier. 


Notification header - see [3]. 


eventTime 


M,F 


ManagedEntity. 
AttributeValueChangedTime 


Notification header - see [3]. 


systemDN 


C,F 


IRPAgent.systemDN where the IRPAgent 
is related to the KernelCmlRP. 


Notification header - see [3]. 


notificationType 


M,F 


Mapped to notificationType in [3] - see 
annex A 


Notification header - see [3]. 


correlatedNotifications 





See comment 


A set of notifications that are correlated to 
the subject notification. Defined in ITU-T 
Recommendation X.733 [10]. 


additionalText 





Text. 


It can contain further information on the 
attribute change of the MO. 


sourcelndicator 





ENUM( 

Resource_operation, 
Management_operation, 
Unknown) 


This parameter, when present, indicates the 
source of the operation that led to the 
generation of this notification type. It can 
have one of the following values: 
resource operation: The notification was 
generated in response to an internal 
operation of the resource; 
management operation: The notification was 
generated in response to a management 
operation applied across the managed object 
boundary external to the managed object; 
unknown: It is not possible to determine the 
source of the operation. 


attributeValueChange 


M 


LIST OF SEQUENCE <AttributeName, 

NewAttributeValue, 

CHOICE [NULL, OldAttributeValue]> 


The changed attributes (name/value pairs) of 
the MO (with both new and, optionally, old 
values). 


NOTE: F in the Qualifier column denotes a Filterable Parameter. 



7.6.6.3 



Triggering Event 



7.6.6.3.1 From-state 

stateBeforeAttributeValueChange. 



Assertion Name 


Definition 


stateBeforeAttributeValueChange 





7.6.6.3.2 To-state 

state AfterAttributeValueChange . 



Assertion Name 


Definition 


stateAfterAttributeValueChange 
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7.7 Interface KernelCmlRPNotifications_4 

7.7.1 notifyCMSynchronizationRecommended (O) 
7.7.1.1 Definition 

IRP Agent notifies the subscribed IRPManager that part of or whole configuration information of the IRP Agent should 
be synchronized. 

The configuration information may lose consistency between IPRAgent and IRPManager for several reasons, such as 
communication failure, NE or EM restarting/initialisation, new network elements being added into networks, etc. In 
such cases, the configuration information should be synchronized between IRPManager and IRP Agent. Normally, when 
there are changes in IRP Agent, these changes are sent to IRPManager through notifications like "notifyObjectCreation", 
"notifyObjectDeletion" or "notifyObjectAttributeValueChange". If there are large changes generated in the network, it 
may be inefficient to send lots of notifications to IRPManager through Itf-N. The notification 

"notifyCMSynchronizationRecommended" is used in this case to efficiently inform the IRPManager of large changes in 
CM. 

In all cases, the baseMOClass, baseMOInstance and scope parameters specify the set of managed network resources 
whose information should be synchronized. 

The recommendation is to send only this notifyCMSynchronizationRecommended notification in such event as 
described above, but there is no guarantee that the IRP Agent succeeds in suppressing all the other CM notifications 
related to MOs defined by the baseMOClass, baseMOInstance and scope parameters. 

If the IRP Agent suppresses any of "notifyObjectCreation", "notifyObjectDeletion" or 

"notifyObjectAttributeValueChange", the IRPManager must subscribe the "notifyCMSynchronizationRecommended" 
in order to be aware of the changes. 

Whenever notifications are suppressed, "notifyCMSynchronizationRecommended" must follow as early as possible. 
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7.7.1.2 



Input Parameters 



Parameter 
Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M,F 


KernelCIVIIRP. ObjectClass 


Notification header - see [3]. 


objectlnstance 


M,F 


KernelCMIRP. objectlnstance 


Notification header - see [3]. This and object class shall 
contain the same information as systemDN. 


notificationid 


M 


This carries the semantics of 
notification identifier. 


Notification header - see [3]. 


eventTime 


M,F 


IVIanagedEntity.creationTime 


Notification header - see [3]. 


systemDN 


C,F 


IRPAgent. systemDN where 
the IRPAgent is related to the 
KernelCmlRP. 


Notification header - see [3]. 


notificationType 


M,F 


IVIapped to notificationType in 
[3] - see annex A 


Notification header - see [3]. 


baseMOCIass 


M 


ManagedEntity.objectClass. 


It specifies the class of the root managed entity of a whole 
subtree, of which the configuration information should be 
synchronized by NM. 


baseMOInstance 


M 


IVIanagedEntity.objectlnstance. 


It specifies the root managed entity of a whole subtree, of 
which the configuration information should be synchronized 
by NM. 


scope 


M 


enum ScopeType 

{ 
BASE ONLY, 
BASE NTH LEVEL, 
BASE SUBTREE, 
BASE ALL 

}; 

struct ScopePara 

{ 
ScopeType type; 
unsigned long level; 

}; 


The scope specifies the number of levels in the tree below 
the baselVIOinstance which are affected by this notification. 


additionalText 





Text. 


It can contain further information on this notification. 


NOTE: F in the Qualifier column denotes a Filterable Parameter. 



7.7.1.3 



Triggering Event 



7.7.1.3.1 From-state 

iRPAgentlnitialisation OR largeChangesDetected 



Assertion Name 


Definition 


iRPAgentlnitialisation 


The IPRAgent begins its internal initialisation and subsequently requires synchronization with 
the network resources. 


largeChangesDetected 


The IRPAgent has detected that large changes has taken place in the network, which 
requires synchronization with the network resources. 



7.7.1.3.2 To-state 

iRPAgentSuccessEmitNotification 



Assertion Name 


Definition 


IRPAgentSuccessEmitNotification 


IRPAgent finished emitting notifyCMSynchronizationRecommended notification. 
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7.8 



Interface KernelCmlRPNotifications 5 



7.8.1 notifyStateChange (O) 



7.8.1.1 



Definition 



IRP Agent notifies the subscribed IRPManager of a change of state and or status of a Managed Object in the NRM. 
The IRP Agent invokes this notification because the subject notification satisfies the filter constraint expressed in the 
IRPManager subscribe operation (see 3GPPTS 32.302 [3]). 

This notification is in part based on the stateChange notification type specified in ITU-T Recommendation 
X.721 [8] and using state management definitions from 3GPP TS 32.672 [6]. 



7.8.1.2 



Input parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M,Y 


ManagedEntity.objectClass 


Notification header - see [3]. 


objectlnstance 


M,Y 


IVIanagedEntity.distinguishedName. 


Notification header - see [3]. 


notificationid 


M, N 


This carries the semantics of notification 
identifier. 


Notification header - see [3]. 


eventlime 


M,Y 


ManagedEntity.StateChangedTime 


Notification header - see [3]. 


systemDN 


C,Y 


IRPAgent.systemDN where the IRPAgent 
is related to the KernelCmlRP. 


Notification header - see [3]. 


notificationType 


M,Y 


Mapped to notificationType in [3] - see 
annex A 


Notification header - see [3]. 


StateChange 


M, N 


LIST OF SEQUENCE 
<StateName (IVI), 
NewStateValue (IVI), 
OldStateValue (Q)> 


The changed state values (name/value pairs) 
of the IVIO (with both new and, optionally, old 
values). 


correlatedNotifications 


0, N 


See comment 


A set of notifications that are correlated to 
the subject notification. Defined in ITU-T 
Recommendation X.733 [10]. 


additionalText 


0, N 


~ 


It can contain further information on the 
attribute change of the MO. 


sourcelndicator 


0, N 


ENUM( 

Resource_operation, 
IVIanagement_operation, 
Unknown) 


This parameter, when present, indicates the 
source of the operation that led to the 
generation of this notification type. It can 
have one of the following values: 
resource operation: The notification was 
generated in response to an internal 
operation of the resource; 
management operation: The notification was 
generated in response to a management 
operation applied across the managed object 
boundary external to the managed object; 
unknown: It is not possible to determine the 
source of the operation. Defined in ITU-T 
Recommendation X. 731 [10]. 


NOTE: Y in the Qualifier column denotes a Filterable Parameter. 



7.8.1.3 



Triggering Event 



7.8.1.3.1 From-state 

stateBeforeStateChange. 



Assertion Name 


Definition 


StateBeforeStateChange 
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7.8.1.3.2 To-state 

stateAfterStateChange. 



Assertion Name 


Definition 


StateAfterStateChange 
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Annex A (normative): 
Notification/Event Types 



The Notification IRP: Information Service (3GPP TS 32.302 [3]) defines an attribute called notif icationType 
that shall be present in all notifications. The present document defines an attribute called eventType that shall be 
present in all CM notifications defined herein. The mapping of this eventType to the notif icationType is 
that they are semantically equal for the CM notifications. Thus, the event types described below (also the same as in 
Release 99) shall be mapped to the notif icationType of the notification header. 

This annex lists and explains Event Types used by Kernel CM IRP and then lists the Event Types valid for each 
notification in this IRP. 

Encoding of eventType is Solution Set dependent. For example, the value of eventType may be encoded as an 
Object Identifier in the CMIP SS and as a numeric string in the CORE A SS. 

The following tables may be extended in the future. 

Table A.I : Event Types 



Event Types 


Explanation 


Object creation 


A notification of this type indicates that a new managed object instance has been created (as 
defined in ITU-T Recommendation X.721 [8] and ITU-T X.730 [9]). 


Object deletion 


A notification of this type indicates that a managed object instance has been deleted (as defined in 
ITU-T Recommendation X.721 [8] and ITU-T Recommendation X.730 [9]). 


Attribute value change 


A notification of this type indicates that the value(s) of one or more attributes have changed (as 
defined in ITU-T Recommendation X.721 [8] and ITU-T Recommendation X.730 [9]). 


CM synchronization 
recommended 


A notification of this type informs NIVI that part of or the whole configuration information of the 
managed system should be synchronized. 


State change 


A notification of this type indicates that the state and/or status of a managed object instance have 
changed (in part based on definitions from X.721 [8] and using state/status definitions from 3GPP 
TS 32.672 [6]). 



Table A.2: Event types applicable to each Notification 



Notification 


Event Type 


notifyObjectCreation 


Object creation 


notifyObjectDeletion 


Object deletion 


notifyAttributeValueChange 


Attribute value change 


notifyCIVISynchronizationRecommended 


CM synchronization recommended 


notifyStateChange 


State change 
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Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Mar 2002 


S 15 


SP-020034 


-- 


-- 


Submitted to TSG SA #15 for Information 


1.0.0 




Sep 2002 


S 17 


SP-020465 


-- 


-- 


Submitted to TSG SA #17 for Approval 


2.0.0 


5.0.0 


Mar 2003 


S_19 


SP-030145 


001 


— 


Add description of notifyCMSyncfironizationRecommended 
notification for KernelCM IRP. 


5.0.0 


6.0.0 


Dec 2003 


S 22 


SP-030630 


003 


-- 


Correction of System Context 


6.0.0 


6.1.0 


Mar 2004 


S 23 


SP-040119 


005 


-- 


Correction of System Context 


6.1.0 


6.2.0 


Jun 2004 


S 24 


SP-040260 


006 


-- 


Add State Management Support to Kernel CM IRP IS 32.622 


6.2.0 


6.3.0 



















































£75/ 



3GPP TS 32.662 version 6.3.0 Release 6 



25 



ETSI TS 132 662 V6.3.0 (2004-06) 



History 



Document history 


V6.3.0 


June 2004 


Publication 



























£75/ 



